RSDK-5986 - module logging propagation and resource-level loggers #312
Conversation
|
@acmorrow fyi, this is still marked as draft because the abort trap issue isn't fully resolved, but I do think it's ready for you to look at whenever you're able. I've managed to significantly reduce (though not eliminate) the occurrence of abort traps, and isolate the failure points when we do get an abort trap. These places are highlighted in comments in the code. Let me know if you want to discuss or have any questions or thoughts! |
| // CR erodkin: every now and again this call causes a failure. From adding log statements | ||
| // in rust-utils, I have confirmed that the failure happens within the rust code. |
There was a problem hiding this comment.
Flagging this, for some reason free_string very occasionally fails in the rust call, specifically here. Because the rust code is so minimal I haven't tried much on that side beyond explicitly dropping the CString, which didn't seem to make a difference.
| BOOST_LOG_TRIVIAL(error) << exc.what(); | ||
| } | ||
| } | ||
| // CR erodkin: three things of note here: |
There was a problem hiding this comment.
Flagging this as well, the majority of abort trap errors happen at the end of the ModuleService destructor, after all owned memory has seemingly been destroyed. It's entirely unclear to me what's going on here.
| /// the third argument. Sets severity to info otherwise. Useful for module | ||
| /// implementations. See LogLevel documentation in the RDK for more information on | ||
| /// how to start modules with a "log-level" commandline argument. | ||
| void set_logger_severity_from_args(int argc, char** argv); |
There was a problem hiding this comment.
This is no longer necessary because we support per-logger severity levels. Additionally, it was causing us to fail to send debug logs to RDK.
Before and after (server side):
Before and after (client side):
